1. Field of the Invention
The present invention pertains to a method and apparatus for reformatting image data prior to printing the data on a printer, and in particular to a method and apparatus for reformatting from a row format to a column format in situations where the image data is sent to the printer row-by-row but where the printer prints the image data column-by-column.
2. Description of the Related Art
Printing apparatuses are widely used in connection with data processing, office automation and personal computer equipment. With advances in technology, it is now possible for printers to have a print head that includes many print elements that are closely spaced with respect to each other. For example, one type of printer currently available includes a single print head having 64 bubble jet nozzles arranged in a single column. Such an arrangement permits speedier printing because an entire "band" of print information can be printed with a single sweep of the print head across the printer carriage.
Image data to be printed by such a printer is ordinarily stored in a bit map memory, that is, each pixel of image data is represented by a separate bit in a byte addressable memory. Due to the above-described structure of the print head, it is advantageous to organize the bit map memory in columns of image data. This organization is advantageous because it allows the print head to print pixels of image data in the same order as bits of image data are read out from the bit map memory.
FIG. 8(a) depicts the desired column-ordered organization for the bit map memory of a band of image data for a typical printer which includes a print head having 64 bubble jet nozzles arranged in a vertical column. The carriage width for the printer is 15 inches across which is printed at 360 dots per inch ("dpi"). Accordingly, as shown in FIG. 8(a), each band of bit map image data is 5400 bits across and 64 bits high. The individual bits in the bit map memory are sequentially ordered in columns. That is, the first 64 bits of bit map memory, namely bits 0 through 63, correspond to the first column of pixels printed by the print head, the second 64 bits of bit map memory, namely bits 64 through 127, correspond to the second column of pixels and so on through the last 64 bits of bit map memory, namely bits 345536 through 345599, which correspond to the 5400th column of pixels printed by the print head.
Typically, the image data in a bit map memory is generated by a host CPU which executes an application program, and the image data is generated and stored in the bit map memory in accordance with the application program. In contrast to the column organization shown in FIG. 8(a), most application programs typically generate image data in row order and store the image data in rows. FIG. 8(b) shows this row-ordered organization for the same band of image data shown in FIG. 8(a). The first row includes bits 0 through 5399, the second row contains bits 5400 through 10799, and so on through the 64th row which contains bits 340200 through 345599.
In the case where the application program in the host computer generates and stores image data in the order shown in FIG. 8(b), it is not possible for a printer of the type in question to print the image data because the individual bits are read from memory in the wrong order. Nor is it practical to skip through a row-ordered bit map memory so as to read out the image data in column order. This is because the bits in bit map memory are grouped into eight bit units called "bytes". For example, referring either to FIG. 8(a) or FIG. 8(b), the first byte contains bit 0 through bit 7, the second byte contains bit 8 through 15, and so on through the 43200th byte. This byte organization makes it difficult to access individual bits within the bytes, and in particular makes it difficult to read, for example, first bit 0 from the first byte in FIG. 8(b), then bit 5400 from the 676th byte, and so on.
To reformat the bit map image data from the FIG. 8(b) row-ordered format to the FIG. 8(a) column-ordered format, it has been considered to program the host CPU to extract desired bits from the FIG. 8(b) bit map memory and to construct a bit map memory in accordance with FIG. 8(a). For several reasons, such an arrangement has proven unsatisfactory. First, because of the byte organization of the bits in the bit map memory, the bit-wise extraction and construction of bit map image memories is a time consuming and CPU-intensive process. The host CPU is well-suited for operating on bytes, but it is not well-suited for operating on individual bits within the byte. Thus, for example, to extract an individual bit from a byte requires the CPU to perform shift operations, masking operations and Boolean logic operations. Similarly, to add a bit to a byte requires Boolean logic operations. Each of these operations takes a finite amount of time and when multiplied by the number of bits in a band (345,600 in the case of FIG. 8(b)) results in unacceptably slow operation. This is especially true in the case of halftone or color image data where several bit map planes may be required.
Second, the primary task for the host CPU is to execute the application program. Any other tasks such as bit map conversions detract from the time available for the host CPU to execute the application program and unacceptably reduce performance.
Third, even if bit map conversion could be accomplished in an acceptably short period of time, the conversion steps required in one type of microprocessor, e.g., an Intel 80386, might not necessarily be the same as those required in a second type of microprocessor, e.g., a Motorola 68000. This is because bit operations are at the most fundamental level of a microprocessor. Accordingly, bit operations for one type of microprocessor are different from bit operations of another type of microprocessor, and a different set of print instruction steps would be needed for each individual type of microprocessor.
It has also been considered to provide a microprocessor in the printer's controller for performing the FIG. 8(b) to FIG. 8(a) conversion. This has also proven to be unsatisfactory because it simply transfers the above noted problems from the host CPU to the printer controller's CPU. Moreover, this approach requires the controller to have a highly sophisticated microprocessor which is inconsistent with the low cost objective for the controller.